> My key concern is that people on the net, and on these lists in > particular, spout opinion as proven fact. This perpetuates folklore, > just as knocking on wood or avoiding black cats. We have no general > evidence to prove in any real way that full disclosre helps/hurts more > people than it hurts/helps. We have no evidence that full disclosure > hastens/delays release of a fix. And we have no evidence that the > majority of "black hats" know and use all of these flaws before they > are publicly announced (although there is some partial evidence to the > countrary). The reason that this debate keeps coming up lies in its nature. Some admins that argue against full disclosure have never experienced a breakin done by a serious cracker who uses little-known bugs to exploit his/her system. I think that most of us should agree that there is a definite stratification in the exposure to privileged security information. For instance, a member of CERT gets a lot more bugs cc'd to them than the wanna-be AOL cracker. This is the way it will always be in a free-enterprise society. Information begs to be hoarded and traded to those who have other information. Full- disclosure or not, the Scott Chasins and Gene Spaffords of the world will always have the knowlege of at least one more bug than the average ".edu" sysadmin. They are the ones who depend on their manufacturer for the bug fix promptly because they lack the ability and/or desire to patch it themselves. Thus, the one who discovers a bug must ask themselves what "layer" they wish to cater to. Do I send it to CERT, and let them take their time? Do I send it to bugtraq and have it get to some admins and approximately half the crackers? Or do I keep it secret and fix it on my site and maybe tell one or two admin friends? These are questions everyone has to ask themselves. >From my experience, on most systems I have been on, a release like 8lgm's latest few -- "There is a bug in at(1), fix it" -- will allow a few crackers and the aforementioned group of admins to write exploits and/or fix it. That level of release does not allow many people to figure out how to fix it in a small amount of time. For myself, if I spent a week or so looking over the closest PD source I could find, and trace(1)ing the binary, I probably could find a fix. Do I have the time to do so? That is another question everyone must decide for themselves. The second level has a crippled exploit, such as the nfsbug program. These do nothing but report problems. They make it much easier to tell if you have a hole, but don't do much about letting you fix it. Still, they allow a few more admins, and a few more crackers exploit it. It takes a little less intelligence to modify something like nfsbug to exploit a file handle, but I would say a good amount of admins and crackers can do so. The lowest level is best typified by the 8lgm releases of last year. A full exploit runnable by the dumbest Unix user and an explicit fix, "type this:", make this the most barbaric of the releases. In this case, the amount of time to fix and exploit it are both reduced. Now it becomes a race to see who can read comp.security.unix first (an admin I know had the passwdrace hole fixed within 3 minutes of the news post hitting our server). So, after looking at all the types of disclosure, I look at them from a typical admin's view. The rodents who use an exploit outright make up about 75% of the crackers and average person will see. These are the ones who get caught easily by doing a "ps uaxww | egrep 'rsh localhost|root' or looking on console for messages like "SU: juser". Full disclosure allows these people to make your life hell because they have no idea what they are doing. On the other hand, if you get the fix first, then you have won. From my view, it's always a toss of the dice who gets the release first. I don't like gambling for my system, so this is not a good thing for me. A large hint at a hole "binmail relies on tempfiles that are created unsafely" allows the average admin the best chance of fixing the hole before the average cracker gets to it. As long as a specific fix is noted, this is the best way. Unfortunately, this scenario is not very common. What usually happens is a subtle threat is released --"install procmail because the Sun patch leaves other holes open" -- and an exploit script circles around the most "3l337" admins and crackers; the mentality is the same. I know this is a fact because I have talked with several admins and crackers that had the 8lgm tmpfile/lockfile exploit script that they are refusing to post. The gripe I have with this is that those same people are the ones advocating no-disclosure. How did they get it? They relied on someone else to provide them with it, hence "partial disclosure". My plea to all you "elites" out there: have some pity on all the lamerz, and throw a tidbit their way every once in a while (said sarcastically). No, the best way is to get the fix out as fast as possible, leaving the exploit as long as possible. In fact, don't write an exploit (said hypocritically). Posting an exploit does nothing except rush people who don't want to be rushed. If it serves your purpose to upset the status quo, do something really daring and give your elite nfo to comp.security.unix, instead of cc'ing it to CERT and Spaf. > If we are going to improve the way we handle security, we have to > start by examining what we really know and not what we have > experienced locally. Every person that read this should look at the level of cracker they have seen and determine which level of release is most right for you. Then, cast your vote (not on this list please :-] ) with your manufacturer or 8lgm or whoever you think it will matter. That's the best way I believe to decide the right approach for you. As for me, I don't foresee anyone making any big changes, but that's up to them to decide. I see a future much like the present, where the "elites" keep the best bugs (kernel and the like), but very few average admins experience a breakin because of it. What you can expect to see is a lot of lame attempts, along with a few surprisingly smarter ones, but don't expect a breakin from some "name brand" hacker with his kernel bug exploit scripts. He'll be targetting the big name admins' machines and succeeding half the time. Don't sweat it too much. Just deal with the crackers on your level and watch what goes on at the lower and higher levels. Don't worry about some big hacker coming down to your level to hack your machine, but take some time to help out the lamer admins you see struggling with the lamer hackers. They'll thank you for it. Thanks for reading this rambling missive (maybe!), Nate